LGTM

@bitcoinhelp, I'm working with @crwatkins on the bitcoin.org wallet reviews. One remaining step on our side is a hands-on physical test of the three Jade models. I can send the shipping details by email.

@devdavidejesus happy to get you some units! just sent over an email

@devdavidejesus happy to get you some units! just sent over an email

Thanks! Just replied to the email.

Blockstream Jade (Classic · Plus · Core) — Review for bitcoin.org listing (PR #4728)

Wallet family: Blockstream Jade — three models: Classic, Plus, Core
Developer: Blockstream
Device type: Hardware wallet (Bitcoin + Liquid)
Audited firmware: 1.0.40 (git tag 1.0.40, commit 6f858f39)
Source repo audited: github.com/Blockstream/Jade (cloned, tag checked out)
Review version: 2026062401
Reviewer: Davi de Jesus
Review feedback incorporated from: Craig Watkins (@crwatkins), reviewer of the original
Jade listing (#4000). His feedback on this PR directly improved the review — see the
"Changes from reviewer feedback" note below.

Changes from @crwatkins's feedback (updated 2026-06-24)

This review was originally posted on 2026-06-23. After @crwatkins's feedback on this PR
(2026-06-24), it was updated on the four points below. Credit for these corrections is his:

1. Taproot feature — he noted that feature selection reflects device capability and
   should not depend on the review's test methodology. This corrected our initial decision
   to omit taproot; the feature is now marked (send + receive of bc1p re-verified in code).
2. 3-month criterion — he confirmed the recommendation to list all three and waive the
   minimum-time criterion on the newest device, and supplied the Coldcard Q precedent
   that we lacked. Verified: the Coldcard Q kept the full good/deterministic transparency
   score with the time clause waived (not a lowered score).
3. Descriptions — he recommended shortening them by removing the Liquid reference and
   the unreviewed companion-wallet references, which also resolves the character-limit issue.
4. H5 (PIN protocol spec) — his original observation in Add Blockstream Jade as HWW #4000 remains the basis of the
   formal-specification suggestion to Blockstream.

Why a single review for the three models

This review covers all three products in PR #4728 in one document because the source-code
audit proved that all three run identical firmware (same tag 1.0.40, same signing,
address, PIN and attestation files). What differs between them is physical hardware
(camera, battery, connectivity) and cosmetics (icon, screenshot, name). The entire
security/firmware assessment is shared; per-model differences are isolated in the
"Per-model differences" section.

PR #4728 is, in practice, a 1→3 split of the existing jade.md: it replicates
identical features and scores from the original file (verified via
git show master:_wallets/jade.md), changing only name, screenshot and icon per model.

Method

• Hands-on physical testing of the three real units: Classic (device A050F8),
  Plus (BDB9CC), Core (BE0704), via the Blockstream/Green app.
• Source-code audit at the exact tag tested (1.0.40), with every claim anchored to
  file:line.
• Live site checks (HSTS, SSL, redirects).

Scope (precedent from PR #4000, @crwatkins): as a hardware wallet, only
hardware/firmware were assessed. The companion software (Blockstream/Green) was used
to operate the devices but not assessed. The units were provided by Blockstream at no
cost.

Verdict per model

As reviewer, I recommend Jade Classic and Jade Plus for listing, with no technical
reservations. Jade Core is technically approved — it passes the same audit (identical
firmware) — but its listing depends on the maintainer's decision regarding the ≥3-month
requirement, which is repo policy rather than a technical matter. This is a reviewer's
recommendation; the merge and any policy decision rest with the maintainer (@Cobra-Bitcoin).

Basic Requirements (shared — identical firmware/company)

Reviewer's organizational numbering.

For hardware wallets (shared — identical firmware)

Conditional criteria that do not apply (N/A): the managing-wallets.md "On desktop
platform" sub-requirements (encrypt the wallet by default; strong KDF/key stretching for
wallet storage) target desktop software wallets — Jade is a hardware device, so they do
not apply. Likewise, the "no access to some private keys in a multi-signature wallet"
sub-requirements (2FA, non-persistent session, etc.) target custodial/co-signed software
models, not a self-custody hardware signer; N/A here.

Genuine Check / attestation (shared)

On first connection the app requires a Genuine Check (mandatory), confirmed on the
device. It is RSA-4096 attestation proven by code: main/process/register_attestation.c
drives the process and main/attestation/attestation.c implements it using mbedtls RSA
(#include <mbedtls/rsa.h>) over the ESP32 Digital Signature peripheral (#include <esp_ds.h>,
rsa_length == ESP_DS_RSA_4096, line 95) — the device signs a challenge with a hardware-protected
RSA-4096 key to prove Blockstream authenticity, which is the cryptographic proof behind the
"Jade is genuine" screen. Exercised in the physical tests.

Features (shared)

features: "bech32 hardware_wallet legacy_addresses multisig segwit taproot"

• bech32 / segwit — PASS "Standard / Native SegWit" policy generates bc1q (tested).
• legacy_addresses — PASS "Legacy SegWit" policy available at account creation.
• multisig — PASS Confirmed in code (main/ui/multisig.c, register_multisig.c).
• hardware_wallet — PASS (it is the device itself).
• taproot — QUALIFIES (send + receive of bc1p, proven by code; see note below).
  This is a change from master (jade.md lacked taproot); adding the feature is a
  recommended correction, per @crwatkins's note on PR Replace Blockstream Jade listing with Jade Classic, Jade Plus, and Jade Core #4728 that feature selection reflects
  device capability and does not depend on the review's test methodology.

Taproot — feature confirmed (send + receive of bc1p, proven by code)

Initially this review left taproot out, reasoning that the tested flow (Blockstream/Green
app) did not make generating a bc1p "easy and obvious". @crwatkins, reviewer of the original
Jade listing (#4000), noted on this PR that feature selection reflects device capability
and should not depend on the review's test methodology — a wallet that can sign Taproot
should carry the feature. Re-checked against the firmware at tag 1.0.40, the capability is
present in both directions the criterion requires:

1. Receive (derive/show a bc1p address): wallet.c:61 defines VARIANT_P2TR "tr(k)";
   wallet.c:936 builds the P2TR scriptpubkey; wallet.c:286-287 maps
   WALLY_SCRIPT_TYPE_P2TR → P2TR; wallet.c:298 lists P2TR among the valid singlesig
   variants; get_receive_address.c routes the variant parameter through the singlesig
   path. Comment at wallet.c:909: "segwit v1 p2tr (keyspend only)" — key-path spending,
   the standard singlesig case.
2. Send (sign a spend from a P2TR input): sign_tx.c:539 counts num_p2tr_to_sign;
   sign_tx.c:797-819 is a dedicated loop that computes the BIP-341 sighash and signs the
   taproot inputs (handling the Liquid genesis-blockhash case too).

Both send and receive are therefore demonstrated in source, satisfying the criterion's
"send and receive Bech32m (bc1p)" requirement.

Note on the tested app vs. capability: in the Blockstream/Green app flow we exercised
hands-on, account creation offered only Native SegWit (bc1q) and Legacy SegWit, with no
Taproot selector on the Receive screen. Via QR/air-gapped, Taproot is selectable
(qrmode.c:207 returns P2TR; the selector at qrmode.c:137 rotates "Legacy → wrapped →
segwit → taproot"). Per @crwatkins's point, feature tagging follows the device's capability
(proven above), not which path the default app exposes — so taproot is marked.

This is a change from master: the original jade.md did not carry taproot. Adding it
to all three files is a recommended correction, not a replication of the prior listing. The
author (@bitcoinhelp) should add taproot to the features line of the three .md files.

Score decisions (shared — identical to master's jade.md)

Verified via git show master:_wallets/jade.md: the 6 scores are identical across the
three PR files and to the original jade.md. The PR replicates, does not alter.

check:
  control: "checkgoodcontrolfull"                    # good: exclusive control (keys on device)
  validation: "checkneutralvalidationvariable"       # neutral: validation via chosen Electrum
  transparency: "checkgoodtransparencydeterministic" # good: open-source + reproducible + >6m + tags
  environment: "checkgoodenvironmenthardware"        # good: dedicated device, no installable apps
  privacy: "checkneutralprivacyvariable"             # neutral: rotates addr, network depends on server
  fees: "checkneutralfeecontrolvariable"             # neutral: fees via companion

• control good — keys on the device, local PIN, blind oracle does not access funds.
• validation neutral — not a full node; validation depends on the Electrum server.
• transparency good/deterministic — CONFIG_APP_REPRODUCIBLE_BUILD=y, REPRODUCIBLE.md,
  tags 1.0.27→1.0.40, repo since 2021 (>6 months). Deterministic build.
• environment good — dedicated hardware, no installable apps.
• privacy neutral — rotates addresses; network privacy depends on the server/Tor.

Per-model differences (what actually changes)

Hardware mapping proven by code (main/Kconfig.projbuild, tag 1.0.40):

All three use the same power file (main/power/jadev20.inc via BOARD_TYPE_JADE_V2_ANY);
camera/battery are gated by #ifdef CONFIG_HAS_CAMERA/HAS_BATTERY, so the code for those
features simply does not compile on the Core.

Literal proof in code: Kconfig.projbuild:72 describes the Core board textually as
"Blockstream Jade Core (Jade v2, no camera, no battery)" — and the BOARD_TYPE_JADE_V2C
block (lines 71-75) selects only HAS_AXP, BOARD_TYPE_JADE_ANY and BOARD_TYPE_JADE_V2_ANY,
without select HAS_CAMERA or select HAS_BATTERY (which V2/Plus has, lines 67-68).
This is not inference: it is Blockstream itself declaring in the code that the Core is the
V2 without camera and without battery.

Jade Core — the 3-month requirement (maintainer's decision)

The Core was publicly launched on 2026-04-28, confirmed by the URL of the official
press release itself (blockstream.com/press-releases/2026-04-28-blockstream-introduces-jade-core/).
As of 2026-06-23 that is ~8 weeks — below the 3-month minimum if the criterion is
applied to the individual model. If applied to the Jade line (since 2021), it passes.

Reviewer's recommendation: apply the criterion to the line. Technical basis (proven in
this audit): the Core runs identical firmware to Plus/Classic (same tag 1.0.40, same
audited security files); it differs only in physical I/O. No new security code is
introduced by the model, so the line's maturity covers the Core. Official confirmation
from Blockstream itself: the blog "The Jade Lineup, Reimagined" states verbatim that
"every device runs identical open-source firmware and the same Blind Oracle security
model"; and the launch press release (2026-04-28) describes the Core as "built on the
same open-source security foundation as the company's existing Jade product line" — i.e.,
the firmware/security equivalence we proved by code is also a public statement by the
manufacturer, across two distinct official documents. Final decision deferred to Cobra
(maintainer) — it is repo policy, not audit.

Assets and PR structure (#4728) — audited on the branch

Structure confirmed on the PR branch (local clone, not web_fetch): jade.md → jadecore.md
and jade.png → jadeclassic.png via git rename; 3 new .md files (level 2, same features
and scores); descriptions in _translations/en.yml:308-310; total diff 11 files,
+62/−6. The 3 .md files have identical content except for id/title/screenshot/text key.

optipng -o7 (required by the criteria): the three screenshots pass — optipng -o7 -simulate
reports each as "already optimized". Dimensions (250×350) and icon size (144×144) also conform.

Note on the en.yml descriptions — character-limit violation (author must fix):
The criteria require each description to be < 320 characters. Measured against the PR
branch:

• walletjadeclassic: 336 chars — exceeds by 16 ❌
• walletjadeplus: 332 chars — exceeds by 12 ❌
• walletjadecore: 314 chars — OK ✓

Two of the three descriptions are over the limit and must be shortened by the author. No
prohibited superlatives were found, and the content (promoting use with Sparrow/Specter/
Nunchuk via QR; see the Taproot discussion above) is otherwise consistent in style. This is
a concrete non-conformance with managing-wallets.md, not a style preference.

PR merge state

Verified via GitHub API and local merge simulation (reconfirmed on 2026-06-23): the PR is
mergeable: false / mergeable_state: dirty — cannot be merged as-is. The branch
is 67 commits behind master (2 ahead) and has not been updated since 2026-05-28.

• _translations/en.yml — auto-merge resolves (no real conflict).
• _wallets/jadecore.md — content CONFLICT requiring manual resolution. Likely cause:
  it is the file renamed from jade.md, which was touched on master in those 67 commits;
  Git does not auto-reconcile rename + edit.

CI (Travis): the PR build passes — Travis CI - Pull Request → completed / success
(head commit 52ffe443, verified 2026-06-19 via GitHub API). The content is valid for CI.
(The API's "combined status: pending" is merely an artifact of GitHub's two APIs —
statuses vs check-runs — not a failure; the actual check is in success.)

Forwarding: the PR content is technically correct (fully audited in this review) and
passes CI, but the author (@bitcoinhelp) needs to rebase onto current master and resolve
the conflict in jadecore.md before any merge. The technical approval in this review
should not be confused with merge-readiness — they are distinct: the code is valid (CI
green), but the merge is blocked by the conflict (dirty state).

Open items and suggestions

Author must fix (concrete non-conformance with managing-wallets.md):

• Description character limit (< 320): walletjadeclassic is 336 chars and
  walletjadeplus is 332 chars — both over the limit (walletjadecore 314, OK). The
  author must shorten the two descriptions. Measured on the PR branch on 2026-06-23.
  Per @crwatkins's review: shorten by removing the reference to Liquid (no other
  non-Bitcoin chain is referenced in any wallet description) and removing references to
  companion wallets other than the native app (Sparrow/Specter/Nunchuk have not been
  reviewed; for consistency other listings don't name them, and naming them could imply a
  recommendation). This both fixes the length and improves consistency.
• PR in dirty state (merge conflict): the branch is 67 commits behind master;
  _wallets/jadecore.md has a content conflict. The author needs to rebase and resolve
  before the merge. Reconfirmed on 2026-06-23 (mergeable: false, branch unchanged since 05-28).

Maintainer's decision (Cobra) — non-technical:

• Jade Core ≥3-month requirement — reviewer's recommendation: list all three and waive
  the minimum-time criterion on the newest device (Core), since the firmware is identical
  across the line. @crwatkins concurs and cites the Coldcard Q precedent. Verified
  against master:_wallets/coldcardq.md: the Coldcard Q kept the full
  checkgoodtransparencydeterministic score (same as the mature Coldcard), with the
  "public ≥6 months" time sub-clause effectively waived because it runs the same auditable
  open-source base. So the precedent is to keep the good/deterministic transparency score
  on the Core and waive the time clause, not to lower the score. The original Jade scores
  (verified identical across the three PR files) already use
  checkgoodtransparencydeterministic, so the Core should keep it. Final decision rests
  with the maintainer.

Improvement suggestions for Blockstream (non-blocking):

1. Publish a formal specification of the PIN/blind-oracle protocol (a direct
   continuation of Craig's observation in Add Blockstream Jade as HWW #4000).
2. Pursue a published independent security audit of the blind-oracle protocol.
3. Better document the SECURE_BOOT_V2_ALLOW_EFUSE_RD_DIS flag in the production README
   (avoids misunderstanding by those who read the config without the context of main.c).
4. Expose the secure-boot/anti-rollback status visibly in the UI to the end user.

Appendix — code anchors (tag 1.0.40, commit 6f858f39)

@devdavidejesus Thanks for the extremely comprehensive review.

In the descriptions (and particularly because they are too long) I would recommend removing the reference to Liquid since no other non-Bitcoin blockchains are referenced in any of the other wallet descriptions. I would also remove references to compatible companion wallets (other than perhaps the native app), especially those that have not been reviewed. We don't want to deny existence, but for consistency other wallets don't list them, and we don't want to imply a recommendation currently or in the future.

Since the firmware is the same on all devices, I would recommend we list all three devices and waive the minimum time criterion (along with the transparency score) on the newest device, as we did on the Coldcard Q for similar reasons.

I also recommend that if the devices can sign Taproot transactions they be listed with the Taproot feature. While criteria are judged based on the default configuration of the device, feature selection is not and should not depend on the review methodology.

@crwatkins Thanks, you're right on all four points, and I've updated the review above accordingly. Credit for these corrections is yours:

1. Taproot — agreed. Feature selection should reflect capability, not the test methodology. I re-verified at tag 1.0.40 that the firmware both receives P2TR (wallet.c builds the P2TR scriptpubkey; P2TR is a valid singlesig variant) and signs P2TR inputs (sign_tx.c has a dedicated BIP-341 signing loop). So taproot should be listed on all three.
2. 3-month criterion / Coldcard Q — agreed. I checked _wallets/coldcardq.md: it kept the full checkgoodtransparencydeterministic score with the time clause waived. The Jade files already use that same score, so the Core keeps it and we waive the time clause.
3. Descriptions — agreed: removing the Liquid reference and the unreviewed companion-wallet references both fixes the length (336 and 332 chars vs. the 320 limit) and keeps consistency with other listings.

@bitcoinhelp — based on the review and Craig's feedback, a few changes are needed on the PR:

1. Add taproot to the features line of all three files (_wallets/jadeclassic.md, jadeplus.md, jadecore.md).
2. Shorten the descriptions in _translations/en.yml to under 320 characters (walletjadeclassic 336, walletjadeplus 332), removing the Liquid and companion-wallet references, as Craig suggests, should do it.
3. Rebase onto current master and resolve the conflict in _wallets/jadecore.md, the branch is currently behind master and not mergeable.

@Cobra-Bitcoin, the only non-technical open item is the 3-month waiver on the Jade Core (launched 2026-04-28). Craig and I both recommend listing all three and waiving the time criterion on the Core, following the Coldcard Q precedent (identical firmware across the line). That decision is yours.